Spring Cloud Hystrix服务容错

在微服务的架构中，服务间通常会形成相互依赖的关系，比如现在有三个微服务节点：A，B和C，B为A的消费者，C为B的消费者。假如由于网络波动或者A服务自身故障，导致B调用A服务的线程被挂起进入长时间的等待。在高并发的情况下可能导致B的资源被耗竭随之崩溃，从而导致C服务也不可用。这种连环式的雪崩效应在微服务中较为常见，为了解决这个问题，服务熔断技术应运而出。熔断一词来自电路学，指的是电路在出现短路状况时，“断路器”能够及时地切断故障电路，避免电路过载发热引发火灾。

类似的，微服务架构中的断路器能够及时地发现故障服务，并向服务调用方返回错误响应，而不是长时间的等待。Spring Cloud Hystrix在Hystrix（又是一款由Netflix开发的开源软件，Github地址https://github.com/Netflix/Hystrix）的基础上进行了封装，提供了服务熔断，服务降级，线程隔离等功能，通过这些功能可以提供服务的容错率。

使用Hystrix

这里将在上一节Spring Cloud Ribbon客户端负载均衡源码的基础上配置Hystrix。

我们先看下在没有配置Hystrix之前，关闭Eureka-Client是什么效果。

分别使用peer1和peer2配置启动Eureka-Server集群，然后启动两个Eureka-Client实例，端口分别为8082和8083，最后启动Ribbon-Consumer。准备完毕后，我们关闭端口为8082的Eureka-Client，然后发送GET请求http://localhost:9000/user/1，返回结果如下：

下面开始使用使用Spring Cloud Hystrix，在项目Ribbon-Consumer中引入Spring Cloud Hystrix依赖：

在入口类上加入或者注解。这两个注解是等价的，查看注解源码就可以证实这一点：

在引入或者注解后，我们的入口类代码如下：

入口类上总共包含了三个注解、和，这三个注解的组合可以使用来代替，源码如下：

接着将UserController中的方法提取出来，创建一个UserService（为了简单起见，不再创建Service接口）：

接着改造UserService的方法：

我们在方法上加入了注解，注解的属性指定了被调用的方法不可用时的回调方法（服务熔断时的回调处理逻辑，即服务降级），这里为方法（必须与方法的参数及返回值类型一致）。

在UserController中调用UserService的方法：

修改完后启动Ribbon-Consumer并重重新启动8082端口的Eureka-Client，发送数次GET请求http://localhost:9000/user/1后，再次关闭8082端口的Eureka-Client。

断开后，继续发送GET请求http://localhost:9000/user/1，当轮询到8082端口时返回数据如下图所示：

可以看到，当轮询到服务不可用时，触发了熔断机制，接口回调了指定的方法。

我们也可以模拟服务超时的情况，可以在Eureka-Client提供的接口方法中设置线程等待，等待时间大于2000（Hystrix默认超时时间为2000 毫秒）即可触发调用方Ribbon-Consumer的服务熔断。

@HystrixCommand详解

注解还包含许多别的属性功能，下面介绍一些常用的属性配置。

服务降级

上面TestController中的中我们用注解指定了服务降级方法。如果方法也抛出异常，那么我们可以再次使用注解指定方法降级的方法，比如定义一个方法：

重启Ribbon-Consumer，并关闭8082端口的Eureka Client服务，访问http://localhost:9000/user/1：

异常处理

在使用注解标注的方法中，除了异常外，别的异常都会触发服务降级。假如我们想指定某个异常不触发服务降级，可以使用注解的属性进行忽略。如：

此外，对于方法抛出的异常信息，我们可以在服务降级的方法中使用对象获取，如：

命名与分组

通过指定注解的、以及属性可以设置命令名称、分组以及线程池划分，如：

上面的配置指定了命令的名称为，组名为，线程池名称为。

通过设置命令组，Hystrix会根据组来组织和统计命令的告警、仪表盘等信息。默认情况下，Hystrix命令通过组名来划分线程池，即组名相同的命令放到同一个线程池里，如果通过设置了线程池名称，则按照线程池名称划分。

当方法被调用时，日志打印如下：

可看到线程名称为getUserThread-1。

Hystrix缓存

我们在Controller中调用三次方法，参数都为1L：

当访问http://localhost:9000/testCache时，控制台输出如下：

开启缓存可以让方法只被调用一次，剩下两次直接从缓存里获取。

开启缓存

要在Hystrix中开启缓存很简单，只需使用注解即可，修改UserService的方法：

通过上面的设定，Hystrix会将返回的User对象进行缓存，缓存的key默认为方法的所有参数，这里只有一个id参数，所以缓存的key为用户id。

这里在测试的时候遇到一个异常：

java.lang.IllegalStateException: Request caching is not available. Maybe you need to initialize the HystrixRequestContext? at com.netflix.hystrix.HystrixRequestCache.get(HystrixRequestCache.java:104) ~[hystrix-core-1.5.12.jar:1.5.12] at com.netflix.hystrix.AbstractCommand$7.call(AbstractCommand.java:478) ~[hystrix-core-1.5.12.jar:1.5.12] at com.netflix.hystrix.AbstractCommand$7.call(AbstractCommand.java:454) ~[hystrix-core-1.5.12.jar:1.5.12] …

在Hystrix的issue中找到了类似的提问：https://github.com/Netflix/Hystrix/issues/1314。

大致意思是在使用Hytrix缓存之前，需要通过初始化Hystrix请求上下文，请求结束之后需要调用方法关闭请求。

所以我们可以定义一个过滤器来实现这个过程：

到这里，我才意识到，其实Hystrix的缓存还是蛮鸡肋的，请求缓存不是只写入一次结果就不再变化的，而是每次请求到达Controller的时候，我们都需要为HystrixRequestContext进行初始化，之前的缓存也就是不存在了，我们是在同一个请求中保证结果相同，同一次请求中的第一次访问后对结果进行缓存，缓存的生命周期只有一次请求！

改造完毕后，重启项目再次访问http://localhost:9000/testCache，控制台输出如下：

设定key值

我们也可以明确的指定缓存的key值是什么。指定key的值有两种方式：

通过注解指定，如：

也可以指定参数对象内部属性为key值：

通过方法来指定，方法的返回值必须是String类型：

值得注意的是，方法2的优先级比方法1高。

缓存清除

在涉及到更新User信息的方法上，我们要及时的清除相应的缓存，否则将会导致缓存数据和实际数据不一致的问题。我们在UserService的方法上做缓存清除操作：

的属性和里定义的一致。

请求合并

请求合并就是将多个单个请求合并成一个请求，去调用服务提供者，从而降低服务提供者负载的，一种应对高并发的解决办法。

Hystrix中提供了一个注解，该注解可以将处于一个很短的时间段（默认10 毫秒）内对同一依赖服务的多个请求进行整合并以批量方式发起请求。为了演示注解的使用方法，我们改造下Eureka-Client（服务提供者）的UserController接口，提供一个批量处理的方法：

然后在Ribbon-Consumer的UserService里添加两个方法：

注解的属性指定了批量处理的方法为下面定义的方法，的值为100（毫秒），意思是在100毫秒这个时间范围内的所有对的调用，都将被合并为一个批量处理操作，进行批量处理操作的方法就是。

我们在TestController中添加一个测试方法：

上面的测试方法中对方法进行了4次的调用，最后一次调用（f4）之前先让线程等待200毫秒（大于中定义的100毫秒），所以我们的预期是前三次调用会被合并，而最后一次调用不会被合并进去。

启动Ribbon-Consumer，访问http://localhost:9000/testRequestMerge,控制台输出如下：

可以看到，控制台的输出符合我们的预期，f1、f2和f3被合并成了一个请求。

而且可以看到，控制台并没有打印出方法中的的日志，实际上方法并不会被调用，所以上面的代码可以简化为：

虽然通过请求的合并可以减轻带宽和服务的压力，但合并请求的过程也会带来额外的开销。就拿上面的来说，比如我们对单个的方法调用耗时5ms，那么调用4次耗时可以粗略的估算为20ms。当我们使用Hystrix的请求合并功能后，前3次请求（f1、f2和f3）进行了合并，第4次请求（f4）没有进行合并，那么耗时可以粗略的估算为（100为上面中指定的时间范围，在该时间段过后，才会调用第4次请求），结果明显比单独调用4次来得高。所以实际中是否该使用Hystrix的请求合并功能，需结合实际需求进行抉择。

Hystrix属性

除了上面涉及到的Hystrix属性配置外，其还包含了大量的别的可用配置。配置可以分为四个级别，优先级从低到高分别为：全局默认配置、全局配置、实例默认值、实例配置。

Commond

execution

： 该属性用来设置执行的隔离策略，它有如下两个选项。

: 通过线程池隔离的策略。它在独立的线程上执行， 并且它的并发限制受线程池中线程数量的限制。

: 通过信号量隔离的策略。它在调用线程上执行， 并且它的并发限制受信号量计数的限制。

实例配置中的HystrixCommandKey对应@HystrixCommand注解中commandKey 属性指定的值。

： 该属性用来配置HystrixCommand执行的超时时间，单位为毫秒。当HystrixCommand执行时间超过该配置值之后， Hystrix会将该执行命令标记为TIMEOUT并进入服务降级处理逻辑。

: 该属性用来配置HystrixCommand的执行是否启用超时时间。默认为true, 如果设置为false, 那么属性的配置将不再起作用。

: 该属性用来配置当HystrixCommand执行超时的时候是否要将它中断。

: 该属性用来配置当HystrixCommand执行被取消的时候是否要将它中断。

: 当HystrixCommand的隔离策略使用信号量的时候，该属性用来配置信号量的大小（并发请求数）。当最大并发请求数达到该设置值时，后续的请求将会被拒绝。

fallback

: 该属性用来设置服务降级策略是否启用，如果设置为false,那么当请求失败或者拒绝发生时，将不会调用降级服务。

circuitBreaker断路器

: 该属性用来确定当服务请求命令失败时， 是否使用断路器来跟踪其健康指标和熔断请求。

: 该属性用来设置在滚动时间窗中，断路器熔断的最小请求数。例如，默认该值为20 的时候，如果滚动时间窗（默认10秒）内仅收到了19个请求， 即使这19个请求都失败了，断路器也不会打开。

: 该属性用来设置当断路器打开之后的休眠时间窗。休眠时间窗结束之后，会将断路器置为“半开” 状态， 尝试熔断的请求命令，如果依然失败就将断路器继续设置为“打开” 状态，如果成功就设置为“关闭” 状态。

: 该属性用来设置断路器打开的错误百分比条件。例如，默认值为5000 的情况下，表示在滚动时间窗中，在请求数量超过阅值的前提下，如果错误请求数的百分比超过50, 就把断路器设置为“打开” 状态， 否则就设置为“关闭” 状态。

: 如果将该属性设置为true, 断路器将强制进入“打开” 状态，它会拒绝所有请求。该属性优先于属性。

: 如果将该属性设置为true, 断路器将强制进入“关闭” 状态， 它会接收所有请求。如果属性为true, 该属性不会生效。

metrics配置

该配置与HystrixCommand执行中捕获的指标信息有关。

: 该属性用来设置滚动时间窗的长度， 单位为毫秒。该时间用于断路器判断健康度时需要收集信息的持续时间。断路器在收集指标信息的时候会根据设置的时间窗长度拆分成多个“桶” 来累计各度量值，每个“桶” 记录了一段时间内的采集指标。例如，当采用默认值10000毫秒时， 断路器默认将其拆分成10个桶（桶的数量也可通过参数设置），每个桶记录1000毫秒内的指标信息。

: 该属性用来设置滚动时间窗统计指标信息时划分“桶” 的数量。

: 该属性用来设置对命令执行的延迟是否使用百分位数来跟踪和计算。如果设置为false，那么所有的概要统计都将返回-1。

: 该属性用来设置百分位统计的滚动窗口的持续时间，单位为毫秒。

: 该属性用来设置百分位统计滚动窗口中使用“桶”的数量。

: 该属性用来设置在执行过程中每个“桶” 中保留的最大执行次数。如果在滚动时间窗内发生超过该设定值的执行次数，就从最初的位置开始重写。例如，将该值设置为100, 滚动窗口为10秒，若在10秒内一个“桶”中发生了500次执行，那么该“桶”中只保留最后的100次执行的统计。另外，增加该值的大小将会增加内存量的消耗，并增加排序百分位数所需的计算时间。

: 该属性用来设置采集影响断路器状态的健康快照（请求的成功、错误百分比）的间隔等待时间。

requestContext

: 此属性用来配置是否开启请求缓存。

collapser

: 该参数用来设置一次请求合并批处理中允许的最大请求数。

: 该参数用来设置批处理过程中每个命令延迟的时间，单位为毫秒。

: 该参数用来设置批处理过程中是否开启请求缓存。

threadPool

: 该参数用来设置执行命令线程池的核心线程数，该值也就是命令执行的最大并发量。

: 该参数用来设置线程池的最大队列大小。当设置为-1时，线程池将使用实现的队列，否则将使用实现的队列。

: 该参数用来为队列设置拒绝阈值。通过该参数，即使队列没有达到最大值也能拒绝请求。该参数主要是对队列的补充， 因为队列不能动态修改它的对象大小，而通过该属性就可以调整拒绝请求的队列大小了。